Web Service testing is typically performed in siloes and follows a bottom-up approach. As a result, a test engineer may lack a top-down view of the business functionality which the Web Service is catering to. The test engineer may have to connect with multiple teams and go through multiple documents to arrive at the functional scenarios that need to be tested, still risking the possibility of missing out on covering a few scenarios. Further, the test data preparation activity for testing Web Services may typically be a highly time consuming manual activity. Depending on the complexity and size of the Web Service request messages this effort could grow to daunting levels. Preparing the Web Service Request XML data combinations covering all the fields (mandatory as well as optional) of the Request XML for the system testing of a Web Service is typically a tedious manual task today. The data scenarios for testing the web service should ensure that all functional scenarios where the Web Service is getting consumed as part of a business process are covered, to start with. The data scenarios should also ensure adequate coverage of all the Request XML fields without compromising on the test coverage.
The manual nature of the web service testing places a high emphasis on highly skilled domain resources since this activity is domain intensive and highly dependent on the domain knowledge of the domain experts. While testing integration between various sub-systems of a web service, generating integration test scripts requires the test engineer to be aware of technical areas including XML, SOAP, etc—thereby creating a dependence on highly skilled domain experts for the testing activity.